In the field of database design, new and more efficient methods for updating and reading data are constantly being sought. Because dynamic memory is generally faster than static memory, a desirable system minimizes the frequency and duration of accesses to static memory. Accordingly, various approaches have been developed that perform data update operations in dynamic memory. However, performing update operations in dynamic memory creates the possibility that the data in static memory may not be valid because the data in static memory does not reflect a modification that has been made to the corresponding data maintained in dynamic memory.
FIG. 1 shows a database system 100 that uses one approach to performing an update operation. In system 100, transaction 102 directly updates data stored in static memory 104. When the transaction 102 modifies data in static memory 104, transaction 102 also generates an undo record and stores the undo record in undo log 106 in static memory 104. The undo record generated in response to an update operation contains information that may be used to remove the changes made during the update operation ("undo" the operation).
FIG. 2 shows how a read operation may be performed in system 100. When data 114 that has been updated is to be read by transaction 102, updated data 114 in static memory 104 is copied to a buffer in buffer pool 108 in dynamic memory 110. The buffered data is then accessed by transaction 102.
The update techniques used by system 100 have several disadvantages. As mentioned above, writing data to static memory 104 is generally slower than writing data to dynamic memory 110, an the direct-update technique used by system 100 accesses static memory 104 for every update. Furthermore, maintaining undo log 106 in static memory 104 requires an additional write operation to static memory 104 for every update. Thus, two writes to relatively slow static memory are required for each update operation. In systems where multiple transactions can run concurrently, transactions compete for permission to directly update data in the database, which may slow the completion of the transactions.
FIG. 3 shows a database system 300 that employs another approach to performing an update operation. In system 300, transaction 302 performs an update operation by writing update information as a log entry 324 stored in a log table 320 in static memory 304 rather than directly updating data in the database. The log entries 324 in the log table 320 describe the modifications to be made to data in static memory 304. Writing process 330 then performs the updates specified in the log entries 324 by modifying the data in the database. As with system 100, transactions in system 300 generate undo records so that updates may be "undone."
FIG. 4 shows how a read operation may be performed in system 300. After writing process 330 updates the data in the database, the updated data may be copied from the database to dynamic memory 310 and stored as buffered data 312. Buffered data 312 is then accessed by transaction 302. However, before transaction 302 can read data that has been updated, writing process 330 must have finished processing the appropriate log entry 324. If writing process 330 has not yet updated the data transaction 302 has requested, transaction 302 must wait.
Because transactions in system 300 do not update the database themselves, some contention issues that arise in system 100 are avoided. However, two writes to static memory 304 are still required for each update operation. Also, transaction 302 must wait for writing process 330 to update data in static memory before that updated data can be read. Because writing process 330 processes log entries 324 from many transactions, a transaction may be required to wait while writing process 330 performs updates to data other than the data desired by the transaction.
Thus, both systems 100 and 300 require transactions to perform two writes to static memory for each update operation. A desirable solution is to queue updates in dynamic memory until the final results of a transaction are determined. All of the modifications can be written to static memory without the possibility that the transaction will change the data again. Because final results are determined before update information is stored in static memory, an undo log is unnecessary.